Scrum 仪式规则——Sprint 评审会议

Sprint 审查会议的时间限制为 4 小时。

• 团队不应花费超过 1 小时来准备 Sprint 评审。
• Sprint 评审的目的是让团队向产品负责人和利益相关者展示已完成的功能。尽管“完成”的含义因组织而异，但它通常意味着功能已完全设计，并且可能被交付或实施。如果“完成”有其他
  含义，请确保产品负责人和利益相关者理解它。
• 无法呈现未“完成”的功能。
• 除非用于支持理解演示的功能，否则不能呈现不是功能的工件。
  工件不能显示为工作产品，并且必须尽量减少它们的使用，以避免混淆利益相关者或要求他们了解系统开发的工作原理。
• 功能应该呈现在团队成员的工作站上，并从最接近生产的服务器执行——通常是质量保证 (QA) 环境服务器。
• Sprint 评审始于团队成员提出 Sprint 目标、承诺的产品待办事项和完成的产品待办事项。然后，不同的团队成员可以讨论 Sprint 中哪些进展顺利，哪些进展不顺利。
• Sprint 审查的大部分时间都花在团队成员展示功能、回答利益相关者关于展示的问题以及注意所需的更改上。
• 在演示结束时，利益相关者会被逐一调查，以了解他们的印象、任何期望的更改以及这些更改的优先级。
• 产品负责人根据反馈与利益相关者和团队讨论产品待办列表的潜在重新安排。
• 利益相关者可以就演示之间潜在可交付产品功能的增加自由发表任何评论、观察或批评。
• 利益相关者可以识别未交付或未按预期交付的功能，并请求将此类功能放在产品待办列表中以进行优先级排序。
• 利益相关者可以在查看演示文稿并请求将功能添加到产品待办列表中以确定优先级时识别他们出现的任何新功能。

Scrum 活动文章

• 什么是 Sprint 计划？
• 什么是 Sprint 审查？
• 什么是 Scrum 中的 Sprint 回顾会议？
• 什么是产品待办列表细化？
• Scrum 中的持续集成/交付/部署是什么？
• Scrum 中的时间盒事件是什么？
• Scrum 中的 Spike 是什么？
• 什么是敏捷规划扑克？